Selective Pairing of Wireless Devices Using Shared Keys

ABSTRACT

A system, a method, and a computer program product for selective pairing of wireless devices are provided. A pairing device scans for an advertising packet. The pairing device checks each scanned advertising packet for a shared key. The pairing device responds to the scanned advertising packet only when the advertising packet contains the shared key.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of U.S. Provisional PatentApplication No. 62/194,939, filed on Jul. 21, 2015, and incorporates itsdisclosure herein by reference in its entirety.

TECHNICAL FIELD

In some implementations, the subject matter described herein generallyrelates to communication systems, and, in particular, to selectivepairing of wireless devices.

BACKGROUND

Modern telecommunications systems serve a vast number of devices, whichcan include wireless telephones, smartphones, tablet computers, personalcomputers, personal digital assistants, and/or other devices. Typically,these devices communicate with one another through various networks thatcan include base stations, wireless access points, servers, etc. Tocommunicate with one another, the devices typically send and/or receivedata packets containing information, e.g., emails, hypertext transferprotocol (“HTTP”) data, message, etc. A data packet includes controlinformation and user data, i.e., a payload. Control information providesdata for delivering the payload (e.g., source and destination networkaddresses, error detection codes, sequencing information, etc.) and isfound in packet headers and trailers.

The data packets can be used to carry advertising information for aparticular product, where various user devices can generate andbroadcast such packets over a communication network. When a devicebroadcasts advertising packets, other devices can determine the types ofproducts that may be found in the vicinity of the devices. While it maybe difficult to intercept data traffic containing such data packets,knowing the types of products that may be available in the vicinity ofthe devices can undesirably reveal personal information. This can leadto a number of privacy and security concerns. For example, one suchconcern relates to recording advertising packets from a cellulartelephone that may be meant for another device. This can lead to use ofthe advertising packets for receiving responses from the device, therebyresulting in a variety of security issues. Further, in someenvironments, such as hospitals, clinics, and/or other public places,multiple BLUETOOTH® Low Energy (“BLE”) devices can be found in arelatively small area. As such, communication devices (e.g., cellulartelephones, smartphones, tablets, etc.) can be provided with an abilityto select one or more of these BLE devices for connection purposes. Someconnections can be unsecured, thereby exposing the connection and theconnecting device to intruders and security breaches. Thus, there is aneed to provide for a way to manage connections to BLE devices withoutsacrificing connection security and speed of the connection.

SUMMARY

In some implementations, the current subject matter relates to acomputer-implemented method for selective pairing of wireless devices.The method can include scanning, by a pairing device, for an advertisingpacket, checking, by the pairing device, each scanned advertising packetfor a shared key, and responding, by the pairing device, to the scannedadvertising packet only when the advertising packet contains the sharedkey.

In some implementations, the current subject matter can include one ormore of the following optional features. The advertising packet cantransmitted by a communication device. The shared key can be in the samebit/byte form between the pairing device and the communication device.The advertising packet can be transmitted via BLUETOOTH® technology. Theshared key can be a global shared key. The shared key can be auser-specific shared key associated with a particular user.

In some implementations, the method can also include scanning, by thepairing device, for a plurality of advertising packets, each advertisingpacket in the plurality of advertising packets containing a portion ofthe shared key, checking, by the pairing device, each scannedadvertising packet for the respective portion of the shared key, andresponding, by the pairing device, to the plurality of scannedadvertising packet only when the entire shared key is found.

In some implementations, the method can also include confirming, by thepairing device, that the advertising packet contains the shared key thatthe pairing device is scanning for, and authorizing, by the pairingdevice, a user based on the confirmed shared key.

In some implementations, the responding can include transmitting one ormore of data attributes, name, serial number, MAC address to acommunication device or a server. The advertising packet can beencrypted. The advertising packet can include the shared key and a textadded to the shared key before the shared key and the added text areencrypted. The text can be varied for each pairing with the pairingdevice.

Computer program products are also described that comprisenon-transitory computer readable media storing instructions, which whenexecuted one or more data processor of one or more computing systems,causes at least one data processor to perform operations herein.Similarly, computer systems are also described that may include one ormore data processors and a memory coupled to the one or more dataprocessors. The memory may temporarily or permanently store instructionsthat cause at least one processor to perform one or more of theoperations described herein. In addition, methods can be implemented byone or more data processors either within a single computing system ordistributed among two or more computing systems.

The details of one or more variations of the subject matter describedherein are set forth in the accompanying drawings and the descriptionbelow. Other features and advantages of the subject matter describedherein will be apparent from the description and drawings, and from theclaims.

BRIEF DESCRIPTION OF THE FIGURES

The accompanying drawings, which are incorporated in and constitute apart of this specification, show certain aspects of the subject matterdisclosed herein and, together with the description, help explain someof the principles associated with the disclosed implementations. In thedrawings,

FIG. 1a illustrates an exemplary system for performing selective sharingof wireless devices using shared keys, according to some implementationsof the current subject matter:

FIG. 1b illustrates another exemplary system, according to someimplementations of the current subject matter;

FIG. 2 illustrates an exemplary system for pairing devices, according tosome implementations of the current subject matter;

FIG. 3 illustrates an exemplary system for pairing devices, according tosome implementations of the current subject matter;

FIG. 4 illustrates an exemplary system for performing shared keyselective pairing (“SKSP”), according to some implementations of thecurrent subject matter;

FIG. 5 illustrates another exemplary system for performing shared keyselective pairing, according to some implementations of the currentsubject matter;

FIG. 6 illustrates another exemplary system for performing shared keyselective pairing, according to some implementations of the currentsubject matter;

FIG. 7 illustrates another exemplary system for performing shared keyselective pairing, according to some implementations of the currentsubject matter:

FIG. 8 illustrates yet another exemplary system for performing sharedkey selective pairing, according to some implementations of the currentsubject matter;

FIG. 9 illustrates another exemplary system for performing shared keyselective pairing, according to some implementations of the currentsubject matter;

FIG. 10 illustrates another exemplary system, according to someimplementations of the current subject matter;

FIG. 11 is a flow chart illustrating an exemplary process for operationof the current subject matter system, according to some implementationsof the current subject matter; and

FIG. 12 is a flow chart illustrating an exemplary process 1200 foroperation of the current subject matter system, according to someimplementations of the current subject matter.

DETAILED DESCRIPTION

In some implementations, the current subject matter relates to selectivepairing of wireless communication devices. The pairing can be performedin a wireless communications system, which can implement a variety ofwireless connection technologies, e.g., WiFi, BLUETOOTH®, long-termevolution (“LTE”) systems, etc. The pairing can be performed by apairing device. The pairing device can scan for an advertising packet(e.g., a data, a packet, and/or a data packet that can containinformation and/or identifier for a particular product beingadvertised). Then, each scanned advertising packet can be checked for ashared key. Only when the shared key is found, the pairing device canrespond to the scanned advertising packet. In some exemplaryimplementations, finding a shred key can be followed by checking whetherthe shared key matches with the right key the pairing device is lookingfor. The pairing device can be programmed to respond to any shared keyand/or to a predetermined key (e.g., the key that it is looking for).

FIG. 1a illustrates an exemplary system 100 for performing selectivesharing of wireless devices using shared keys, according to someimplementations of the current subject matter. The system 100 caninclude a device 1 110, a device 2 120, and a server 130, each of whichcan be communicatively coupled to one another via various communicationstechnologies.

The device 1 can be a pairing device that can include a softwarecomponent 111, BLUETOOTH® Low Energy (“BLE”) communication capabilitycomponent 112, and one or more sensors 113. The device 1 can alsoreferred to as the selective pairing or “stealth” device. The device 1110 can be provided with selective pairing technology capabilities(e.g., software and/or hardware including computer instructions thatwhen executed by one or more processors implements one or more featuresof the current subject matter). In some implementations, the device 1can include a data memory, which can be larger than other sensor devices(e.g., existing devices that do not operate in the selective pairingmode). This can allow storage of additional sensor data that is nottransmitted while device 1 operates in the selective pairing mode (orthe “stealth” mode) prior to pairing.

In some implementations, device 1 110 might not require human-machineinterface (“HMI”) for BLE purposes. In some implementations, device 1110 can include an input mechanism (not shown in FIG. 1a ), such as oneor more buttons, a touchscreen, a keyboard, and/or any other suitablemechanisms. The input mechanism can facilitate the pairing process,e.g., by enabling a user of the device 1 to enter a passcode, select apairing option, etc., and/or perform various other functions, e.g., toreset the device 1.

In some implementations, device 2 120 can be a communication device thatcan be communicatively coupled (e.g., via a BLE, WiFi, etc.) with thepairing device 110. The device 2 can include a software component 121, aBLE communication capability component 122, and a mobile network and/orWi-Fi adaptor component(s) 123. In some implementations, the device 2can be a user equipment, e.g. a cellular telephone, a smartphone, atablet, and/or other computing device, having internet accesscapability. The network adaptor component 123 can be used to communicatedata via a mobile network, Wi-Fi, and/or any other technologies (e.g.,Zigbee, Sub-GHz, etc.). The device 2 120 can also include BLEcapabilities as well as selective pairing technology capabilities.

In some implementations, the device 2 120 can be communicatively coupledto a server 130, e.g., via a mobile network, Wi-Fi, and/or any otherdata communication technologies. In some implementations, the server 130can include an account data repository 131, which can include a databasefor storing user info including, for example, shared key(s), accessright level, etc. In some implementations, a user can manage the accountdata repository 131 via a communication device 120. The server 130 caninstruct the device 2 120 to connect with the device 1 110 toreceive/transmit data/information, e.g., from the one or more sensor(s)113. The server 130 can also manage device 1 110 and device 2 120. Thesystem 100 can be particularly useful, for example, in situations wheredata collection and/or control of the pairing device is/are performedwithout human intervention.

FIG. 1b illustrates an exemplary system 140, according to someimplementations of the current subject matter. The system 140 caninclude a sensor 1 150, a sensor 2 155, a device 1 160, a device 2 170and a server 180, which can include an account data repository 181. Thesystem 140 bears some similarity to system 100 shown in FIG. 1a . Asshown in FIG. 1b , the device 1 160 can include a software component161, a wired/USB/wireless/Wi-Fi component 162, and a BLE component 163.The device 160 can be communicatively coupled to the sensor 1 150 andsensor 2 155. The device 160 can obtain one or more sensor data from thesensors 150, 155. The current subject matter is not limited to the twosensors 150, 155, and as can be understood by one skilled in the art,any number of sensor devices can be provided. Additionally, the device 1160 can also include one or more sensors (not shown in FIG. 1b ).

The device 2 170 can include a software component 171, a BLE component172, and a mobile network and/or Wi-Fi component 173. Similar to thedevices 110 and 120 shown in FIG. 1a , the device 2 170 can becommunicatively coupled with the device 1 160, such as via BLEcommunications technology.

The sensor device 150 can include a software component 151 and a sensorcomponent(s) 152. Similarly, the sensor device 155 can include asoftware component 156 and a sensor component(s) 157. As stated above,sensors 150, 155 can provide various sensor data to the device 1 160.

While FIGS. 1a-b illustrate two devices (i.e., devices 1 and 2), as canbe understood by one skilled in the art, any number of devices can beincluded in the current subject matter's communications systems, as forexample, illustrated in FIGS. 2 and 3 and discussed below.

FIG. 2 illustrates an exemplary system 200 for pairing devices,according to some implementations of the current subject matter. Thesystem 200 can include a pairing device 1 210, communication device 2220, communication device 3 230, communication device 4 240 and a server250. The device 210 can include a software component 211, a BLEcomponent 212, and sensor(s) 213. The devices 220-240 can include BLEcomponents 221, 231, 241, respectively, and mobile/Wi-Fi components 222,232, 242, respectively. The devices 220-240 can be communicativelycoupled with the pairing device 210 as well as the server 250. Theserver 250 can include an account data repository 251 for storage ofaccount information pertaining to a particular user and/or a device, anda shared keys repository 252.

Devices 220-240 and/or their users can access account information storedin the server 250 and can receive one or more shared key(s) 252 fromserver 250. Users can also create user accounts for storage on theserver 250, register their devices (e.g., device 210) and associate theregistered devices with their account. As can be understood any numberof servers 250 can be included in the system 200.

In some implementations, a user can log into the server 250 from one ofthe communication devices 220-240. Once the user is successfullyauthenticated by the server 250, the user can manage one or more of thepairings between the pairing device 210 and the communication devices220-240. For example, if the user wishes to pair a new pairing devicethat had not been paired before, the server 250 can generate and/orretrieve a shared key from the shared key repository 252 and transmitthe shared key to the communication device using which the user iscommunicating with the server 250. The shared key can then bedistributed to the pairing device. This process can be repeated for eachpairing device that the user wish to pair. To increase security, thepairing device(s) can respond only to packets that have been signed(and/or acknowledged) using a shared key. In some implementations, theshared key can have a fixed and/or variable length of digital data. Itcan be several digits to 128 bits, 256 bits, etc. It can have astructure similar to a header and can include an identifier to specifytype of device 1, device 2, a server, and/or a user. In some exemplaryimplementations, the shared key can be a random binary string. Theshared key can be generated on the server side so that the server candetermine whether the generated key is a unique binary string in thesystem. As shown in FIG. 2, the shared key repository 252 can containone or more shared keys.

FIG. 3 illustrates an exemplary system 300 for pairing devices,according to some implementations of the current subject matter. System300 is similar to the system 200 shown in FIG. 2. The system 300 caninclude a plurality of pairing devices 1 a 311, 1 b 312, and 1 c 313, aplurality of communication devices 2 321, 3 322, 4 323, and a server330. The pairing devices 311-313 can include respective BLE componentsand/or any other components. Similar to the communication devices ofsystem 200, the communication devices include respective BLE andmobile/Wi-Fi components. Any pairing device 311-313 can communicate withany communication device 321-323. As stated above, any number of pairingdevices, communication devices, and/or servers can be provided.

In some implementations, the server 330 can store a single key that canbe used for multiple pairing devices. The single key can be a globalshared key and/or a user-specific shared key. The global shared key canbe a key that is not unique to user and/or a user account. In someexemplary implementations, same products, manufacturer(s), type(s) ofproduct, make(s), etc. can be assigned the same global shared key whenthey are shipped from a manufacturer. When a product type is known,e.g., a user purchased a new device that needs to be paired for thefirst time, device 2 can advertise a global shared key, which is knownthat that product can accept, and initiate communication with device 1,which is in stealth mode. In some exemplary implementations, the globalshared key, i.e., the data string itself, might not be published. A userspecific shared key can be the same kind of data string as the globalshared key and its structure and use are further discussed below. Keylengths of the global shared key and the user specific shared key can bethe same and/or different.

In alternative implementations, different keys can be generated andstored by the server 330. Each such key can be assigned to one or morepairing devices. For example, at the time of manufacturing/shipment ofdevices 311-313, different global shared keys can be generated andstored for each device 311-313. A single and/or a plurality of pairingdevices can be associated with a single user account. Each pairingdevice can have a different global key and/or user-specific shared key.The server 330 can store the key and associate it and/or stored ittogether with the user account information.

In some implementations, the communication devices 321-323 can transmitraw shared key values in an advertising data packet (i.e., a data, apacket, and/or a data packet containing information about a particularproduct being advertised) and/or any other data packet to pairingdevice(s) 311-313. In some implementations, the raw shared key valuescan indicate that the shared keys can be strings of binary data, asdiscussed above. The values are transmitted in such a way that thepairing device(s) 311-313 do not need to decrypt all data packets allthe time, thereby saving energy consumption and/or computing power. Insome implementations, the advertising data packet payload containingshared keys can be encrypted. This can ensure that the informationtransmitted will not be accessed by anyone who is not authorized to doso. Further, additional measures of security, as discussed below, can beimplemented.

In some implementations, a shared key (e.g., global or user-specific)can be shared in the same bits/bytes form among the pairing device,communication device, and/or server. In some implementations, even ifencrypted, the shared key can be identical, for example, bit by bit,when decrypted. In some implementations, a shared key need not beidentical, for example, between/among the pairing device, communicationdevice, and/or server. For example, the pairing device can have aninternal conversion table to convert a piece of information the pairingdevice received (that is different from the key itself) to the key thatis intended to be used.

In some implementations, a pairing device can be configured to receiveone or more user-specific shared keys (and its update(s) as well asupdated global shared key(s)). Instead of receiving a key in one pieceof information, the pairing device can receive two or more pieces ofinformation from a communication device and/or a server to construct theshared key internally based on these pieces of information. The piecesof information for constructing a shared key can be transmittedseparately. This can be particularly useful in order to increasesecurity by separating the pieces of information such that the sharedkey cannot be reconstructed without all of the pieces. Thus, an attacker(e.g., a hacker) who received only some of the pieces of informationcannot reconstruct the shared key and will not be able to access thedevice.

In some implementations, the pairing device can be provided with aprivate key. The communicating device and/or server can encrypt theshared key with a public key, and can transmit the encrypted shared keyto the pairing device. In this way, the pairing device needs two piecesof information (i.e., the private key and an encrypted shared key data)to decrypt and obtain the shared key.

In some implementations, the shared key can be further concealed (inaddition to encryption) by appending various data to the shared keyprior to encryption. Adding text to the shared key can vary the cyphertext so that the cypher text and the encrypted advertising packetpayload can be different each time. In some exemplary implementations, apart and/or whole of access address, which can be a part in the header,can be added to the shared key prior to encryption. The access addresscan be a different value in each attempt of shared key selective paringprocess. The access address can be changed each time. In alternateexemplary implementations, the access address can be fixed for apredetermined period of time and/or for a number of pairing attempts. Insome exemplary implementations, each advertising packet can have adifferent access address. The added text can be obtained from the headerof the packet. Upon receipt of the shared key with the additional text,device 1 can decrypt the payload and determine whether the decryptedshared key matches one of the known shared keys, and/or whether thedecrypted payload contains a part of the header of the packet to verifythat the payload was actually encrypted by the trusted device 2. If thedecrypted payload does not contain a part of the header, the device 1can determine that the payload is not an authentic advertising packetand thus, will not respond to it, e.g., by staying in stealth mode.

FIG. 4 illustrates an exemplary system 400 for performing shared keyselective pairing (“SKSP”), according to some implementations of thecurrent subject matter. The system 400 can include a pairing device 1410, a communication device 2 420 and a server 430. The devices 1 and 2can be communicatively coupled with a BLUETOOTH® connection and/or anyother connection. Device 2 and the server 430 can be communicativelycoupled via a network, e.g., an Internet, WAN, LAN, MAN, etc. To improvedata security, the pairing device 410 can selectively pair with thecommunication device 420, such that the pairing device 410 cantransmit/broadcast (e.g., the pairing device can be a beacon that cantransmit data which can be received by any device in its vicinity) dataonly in response to a communication from the communication device 420,which can include a shared key that is recognized by the pairing device410.

The selective pairing technology described herein is particularlyadvantageous when the pairing device 410 contains sensitive privatedata, such as, medical data, patient data, banking transaction data,and/or any other private data. For example, the pairing device 410 canbe a blood glucose meter, a body composition meter, a blood pressuremeter, a thermometer, a heart rate monitor, etc. One or more of thepairing devices 410 can communicate with one or more communicationdevices 420, which can include at least one of the following: a cellulartelephone, a smartphone, a tablet, a personal computer, a laptop, etc.The communication device(s) 420 can communicate with the server 430 inorder to, for example, manage a user account that can be accessed usingthe pairing device 410.

FIG. 5 illustrates another exemplary system 500 for performing sharedkey selective pairing, according to some implementations of the currentsubject matter. The system 500 can include a pairing device 1 510, acommunication device 2 520 and a server 530. The devices 1 and 2 can becommunicatively coupled with a BLUETOOTH® connection and/or any otherconnection. Device 2 and the server 530 can be communicatively coupledvia a network, e.g., a mobile Wi-Fi network and/or any other network.The pairing device 510 can include one or more sensors, as describedabove. During process performed by the system 500, the pairing device510 does not broadcast data indiscriminately, rather, it can scan foradvertising packets using a shared key, e.g., global and/oruser-specific key, and only respond when a shared key is found in theadvertising packet payload. In some exemplary implementations, thepairing device can look for a set of numbers that can share the samemathematical characteristics, which can mean that instead of looking foran exact match with keys stored by the pairing device, the pairingdevice can plug a number from the set of numbers into a function todetermine whether there is match with characteristics of the set ofnumbers. Once the shared key is found, the pairing device 510 cantransmit data including at least one of the following: dataattribute(s), name(s), serial number(s), MAC address(es), etc., to thecommunication device 520 as a part of device registration. In someimplementations, both types of shared keys can be updated using thecommunication device 520. The communication device 520 can be at leastone of the following: a telephone, a mobile telephone, a smartphone, atablet, a personal computer, a laptop, and/or any other device.

The communication device 520 can broadcast advertising packets only whennecessary. The communication device 520 can include a global key insidethe advertising packet payload, and/or a user-specific key, as desired,e.g., after the pairing device 510 has been registered with a useraccount. In some implementations, the registration of the pairing device510 can include storing the pairing device's MAC address and/or productserial number.

The server 530 can include a database that stores various data for eachuser account including at least one of the following: a user name, ane-mail address, a product type, a MAC address, a serial number, a globalshared key, a user-specific key(s), and/or any other information.

In some implementations, the pairing device 510 can broadcast anadvertising packet containing a product name and/or any ID code. A usercan use the communication device 520 to start scanning and look for apredetermined product name and/or ID code. Once the user selected theproduct name and/or ID code of the pairing device 510, a pairing betweenthe devices 510 and 520 can be initiated and a BLE connection can beestablished. A specific shared key for the user and the pairing device510 combination can be generated at the server 530 and/or at the device520 and can be sent to the pairing device 510. In some implementations,the shared key may not be based on and/or derived from the device serialnumber and/or MAC address and/or be based on a unique value that can bespecific to the pairing device 510 and/or the communication device 520,and/or a value generated based on devices' hardware specific values. Insome implementations, the shared key can be unique to the user and canbe generated without any dependency on the pairing device and/or thecommunication device.

In some implementations, the pairing device 510, communication device520, and the server 530 can all store the same shared key, e.g., aglobal and/or a user-specific shared key. In some implementations, oncethe pairing device 510 has the shared key, it can stop broadcastingadvertising packets and move to scan mode, thereby entering a selectivepairing or “stealth” mode. In some exemplary implementations, the device520 and the server 530 can share the same shared key, e.g., auser-specific shared key. Alternatively, the devices 510, 520 and theserver 530 can share the same shared key, e.g., a global shared key.Further, in alternate implementations, the device 510 may or may nothave a shared key. Moreover, the device 510 can broadcast an advertisingpacket so that the device 520 can find it and establish a connection. Infurther implementations, the device 520 can confirm that the device 510has the appropriate key, e.g., a global shared key. For example, aconfirmation of the device 510 identifier can be sufficient to confirmthat device 510 is the device that the device 520 was looking for.Alternatively, the device 510 can receive a user-specific shared keyfrom the device 520 and can enter into a selective pairing or stealthmode. In the stealth mode, the communication device 520 can initiatecommunication with the pairing device 510 by broadcasting advertisingpacket(s) that can contain a shared key, e.g., a global and/or auser-specific shared key, that was already stored and/or pre-set in thepairing device 510, e.g., when the product was made and/or at the timeof product shipment. The pairing device 510 can scan for advertisingpacket(s) from the communication device 520 and can match the shared keycontained in the packet to the pre-set shared key of the pairing device510. When a match is found, the pairing device 510 can send a connectionrequest in response to the advertising packet from the communicationdevice to establish pairing and can maintain connection between thedevices.

In some implementations, a global shared key can also be shared betweendevices 510, 520 and the server 530. In some implementations, the globalshared key can be shared only among the same product type and softwareapplication type running on the device 520.

In some implementations, the pairing device may never need to broadcastany advertisement packets in use. For example, the pairing device cancommunicate with a communication device using a global shared key. Insome implementations, further communications can also be establishedusing a user-specific shared key instead of a global shared key.

In some implementations, the pairing device can receive a specificshared key for a specific combination of the pairing device and theuser, and can store it for future use.

In some implementations, there can be two or more global shared keys.For example, one key can be a general-purpose key stored on the pairingdevice, which can be stored at the time of shipment of the device fromits manufacturer, and the other one key can be a global key that can benewly stored in the pairing device and/or a replacement general purposekey. In some implementations, the pre-set key can become known, andthus, the pairing device can be updated (e.g., on-demand, frequently,periodically, manually, etc.) with a new replacement global key in orderto improve security.

In some implementations, in order to use the current subject mattersystem, the user can be requested by the communication device (e.g.,devices 220, 230, 240, as shown in FIG. 2) to enter user's logininformation in order to login into user's account. If the user isalready logged in, the communication device can perform one or morechecks. The checks can include at least one of the following: a checkfor device registration status, shared key(s), a measurement of dataupdate, a change flag to determine whether there are other tasks for thecommunication device to execute (other than receiving data from thepairing device, and/or changing pairing device state(s)) and/or anyother checks. The checks can be used to ensure proper operation of thecurrent subject matter system.

The device registration status can include an indication as to whetherthe device is or is not registered to any user or to which user accountthe device is registered. For example, if the device is registered to asecond user account, access to the device from a first user account,that is different from the second user account, can be denied. This canprevent registration and/or use of the device that is registered to auser account that is not the account that is being used to access thedevice. This can prevent duplicate device registrations, which can causedata incoherency and/or other problems.

When the communication device needs to connect with the pairing device(e.g., to receive data from the pairing device and/or to send out dataand/or instructions to the pairing device), the communication device canbroadcast one or more advertising packets. The advertising packets cancontain the communication device and/or the pairing device's addresses.Using such advertising packets, the communication device can performdirect advertising of a product. The communication device can establisha fast connection by using directed advertising packet that can containthe communication device's and/or the pairing device's addresses. Thispacket can be sent continuously.

In some implementations, the pairing device, upon receiving theadvertising packet, can compare a length and a type of informationcontained in the received advertising packet with predetermined valuesof the length and type. If there is no match, the pairing device canignore the advertising packet and does not process it. If there is amatch, the pairing device can inspect the shared key value contained inthe advertising packet. In some exemplary implementations, the sharedkey value can include two components: one component can indicate thatthe communication device is a selective-pairing enabled device, and theother component can be specific to a combination of the pairing deviceand/or user account being used to access the device. If the pairingdevice determines that the shared key is valid, the pairing device cantransmit a connection request packet to the communication device. Oncethe connection is established, the pairing device can transmit and/orreceive data to/from the communication device. Upon establishment of theconnection, the communication device can also synchronize datatransmitted/received to/from the pairing device with the server.

In some implementations, the advertising packets that use the sameshared key can be varied by adding data and/or additional text to thecypher text contained in the advertising packets prior to encryption ofthe packets. This can enhance security by preventing an unauthorizedconnection to the pairing device through reuse of one or more of thesame advertising packets that had been broadcasted before. This can alsoconceal the shared key as it would be difficult to identify the sharedkey contained in the additional data and/or text. In someimplementations, a part of and/or an entire header of the advertisingpacket, such as an access address, can be used as the additionaldata/text to be included with the shared key. Upon receipt of theadvertising packet, the pairing device can verify the shared key anddetermine whether the advertising packet was actually encrypted by thecommunication device. For example, if the decrypted advertising packetdoes not contain a part of the header, the pairing device can determinethat the advertising packet is not an authentic SKSP advertising packet,and thus, remain in a stealth mode.

Similar process can be applicable to systems that can include multiplepairing devices and/or multiple communication devices, which can beaccessed by the user, as shown in FIG. 3. The multiple pairing devicescan be registered to a single user account contained on the server 330,as shown in FIG. 3, to allow sharing of the same user-specific sharedkey. Thus, when communication device 321 broadcasts an advertisingpacket with the user-specific shared key, all pairing devices 311-313can respond and the communication device 321 can transmit/receive datato/from any and/or all of the pairing devices. In some implementations,the communication device 321 can operate in an offline mode, in whichdevice 321 has no and/or intermittent connection with the server 330. Inthe offline mode, device 321 can perform functions of the server 330. Inan offline mode, device 321 can communicate with devices 311-313 becausedevice 321 can store a user-specific shared key. Device 321 cansynchronize with server 330 when connection is available. In particular,device 321 can switch between online mode and offline mode. Moreover,when connection is not available, device 321 can manually and/orautomatically enter into the offline mode. The device can enter onlinemode when connection is available manually and/or automatically.

FIG. 6 illustrates another exemplary system 600 for performing sharedkey selective pairing, according to some implementations of the currentsubject matter. The system 600 can include a pairing device 1 610, acommunication device 2 620, a server 630, and an on premise devicemanagement station 640. The devices 1 and 2 can be communicativelycoupled with a BLUETOOTH® connection and/or any other connection. Device2 and the server 630 can be communicatively coupled via a network, e.g.,a mobile Wi-Fi network, WAN, LAN, MAN, Internet, and/or any othernetwork. The station 640 can be communicatively coupled with the device610 using a network, e.g., a mobile Wi-Fi network, WAN, LAN, MAN,Internet, and/or any other network, as well as using a directconnection, such as a USB. Additionally, the station 640 can also becommunicatively coupled with the server 630 via a network, e.g., amobile Wi-Fi network, WAN, LAN, MAN, Internet, and/or any other network,as well as using a direct connection. Cloud servers and/or on premiseservers can be used to provide connection between the station 640 andthe server 630. In some exemplary implementations, the system 600 can beimplemented in a hospital setting. Device 610 can include at least oneof the following: a blood glucose meter, a body composition meter, ablood pressure meter, a thermometer, a heart rate monitor, and/or anyother medical and/or non-medical device. Device 620 can be a mobiletelephone, a smartphone, a tablet, a personal computer, a laptop, and/orany other device. The sever 630 can be a cloud server and/or any othertype of server. The server 630 can perform processing and/or storage ofdata and can include one or more processors and/or more memorylocations. In some exemplary implementations, the device managementstation can be a battery charger, a communication bridge between device610 and the server 620, and/or any other type of device.

FIG. 7 illustrates another exemplary system 700 for performing sharedkey selective pairing, according to some implementations of the currentsubject matter. The system 700 can include a pairing device 1 710, acommunication device 2 720, a server 730, and a reservation managementsystem 740. The devices 1 and 2 can be communicatively coupled with aBLUETOOTH® connection and/or any other connection. Device 2 and theserver 730 can be communicatively coupled via a network, e.g., a mobileWi-Fi network, WAN, LAN, MAN, Internet, and/or any other network. Thesystem 740 can be communicatively coupled with the server 730 using anetwork, e.g., a mobile Wi-Fi network, WAN, LAN, MAN, Internet, and/orany other network, as well as using a direct connection. Cloud serversand/or on premise servers can be used to provide connection between thesystem 740 and the server 730.

In some exemplary implementations, the system 700 can be implemented ina hotel and/or a facilities management setting. Device 710 can includeat least one of the following: a door lock mechanism in a hotel, office,home, locker room, amusement park entrance, a security sensor, autilities management sensor (e.g., air conditioning, heating, lighting,etc.), automotive keyless entry system, e.g., automotive keyless entryfor a rental car and/or car sharing, and/or any other medical and/ornon-medical device. Device 720 can be a mobile telephone, a smartphone,a tablet, a personal computer, a laptop, and/or any other device. Thesever 730 can be a cloud server and/or any other type of server. Theserver 730 can perform processing and/or storage of data and can includeone or more processors and/or more memory locations.

FIG. 8 illustrates yet another exemplary system 800 for performingshared key selective pairing, according to some implementations of thecurrent subject matter. The system 800 is similar to the system 700shown in FIG. 7 and can be used in a similar setting as the system 700.The system 800 can include a pairing device 1 810, a communicationdevice 2 820, a server 830, and a reservation management system 840. Thedevices 1 and 2 can be communicatively coupled with a BLUETOOTH®connection and/or any other connection. Device 2 and the server 830 canbe communicatively coupled via a network, e.g., a mobile Wi-Fi network,WAN, LAN, MAN, Internet, and/or any other network. The system 840 can becommunicatively coupled with the server 830 using a network, e.g., amobile Wi-Fi network, WAN, LAN, MAN, Internet, and/or any other network,as well as using a direct connection. Cloud servers and/or on premiseservers can be used to provide connection between the system 840 and theserver 830. A user 850 can be communicatively coupled and can access thedevice 820 and the reservation management system 840.

In some exemplary implementations and similar to the system 700 shown inFIG. 7, the system 800 can be used in a hotel and/or a facilitiesmanagement setting. Device 810 can include at least one of thefollowing: a door lock mechanism in a hotel, office, home, locker room,amusement park entrance, a security sensor, a utilities managementsensor (e.g., air conditioning, heating, lighting, etc.), automotivekeyless entry system, e.g., automotive keyless entry for a rental carand/or car sharing, and/or any device. Device 820 can be a mobiletelephone, a smartphone, a tablet, a personal computer, a laptop, a carkey, and/or any other device. The sever 830 can be a cloud server and/orany other type of server. The server 830 can perform processing and/orstorage of data and can include one or more processors and/or morememory locations.

In some implementations, the user 850 can use the system 800 to purchasea hotel room stay by accessing the reservation management system 840 viadevice 820. To do so, the user 850 can use the device 820 to login tothe server 830 using the user account information in order to receivedata/information from the server 830. The server 830 can store useraccount information that can include at least one of the following: username, contact information, MAC address and/or S/N, global shared key,user specific key, and/or any other information to identify the user.The device 820 can then broadcast an advertising packet, which caninclude a global key and/or a user-specific key in the advertisingpacket's payload. The user-specific key can be included in the payloadonce the device 810's MAC address and/or S/N are confirmed to be validwith data stored on the server 830. Device 820 using the user specifickey can then lock/unlock device 810.

Similar to the systems discussed in connection with FIGS. 1a -7, thedevice 810 can also perform scanning for advertising packets containingglobal shared key and/or advertising packets containing user specifickey once the devices are registered to a particular user. The device 810can respond to the packets only when a particular shared key is found inadvertising packet's payload. Once the shared key is found, device 810'sattributes, name, S/N, MAC address, etc. can be sent to device 820 as apart of device registration and both types of keys can be updated bydevice 820.

The server 830 can also store MAC address/lock location lookup table.The table can be accessed by the reservation management system 840 toprovide access to the room during the stay as purchased by the user. Theaccess can also be granted to cleaning crew and/or other authorizedindividuals by an administrator of the reservation management system840.

FIG. 9 illustrates another exemplary system 900 for performing sharedkey selective pairing, according to some implementations of the currentsubject matter. The system 900 can be similar to the system 800 shown inFIG. 8 and can include a pairing device 1 910, a communication device 2920, a server 930, a reservation management system 940, a securitysystem 950, and an on premise door lock management station system 960.The devices 1 and 2 can be communicatively coupled with a BLUETOOTH®connection and/or any other connection. Device 2 and the server 930 canbe communicatively coupled via a network, e.g., a mobile Wi-Fi network,WAN, LAN, MAN, Internet, and/or any other network. The system 940 can becommunicatively coupled with the server 930 using a network, e.g., amobile Wi-Fi network, WAN, LAN, MAN, Internet, and/or any other network,as well as using a direct connection. The system 950 can becommunicatively coupled with the server 930 using a network, e.g., amobile Wi-Fi network, WAN, LAN, MAN, Internet, and/or any other network,as well as using a direct connection. The station 960 can becommunicatively coupled with the device 910 using a network, e.g., amobile Wi-Fi network, WAN, LAN, MAN, Internet, and/or any other network,as well as using a direct connection, such as a USB. Additionally, thestation 960 can also be communicatively coupled with the server 930 viaa network, e.g., a mobile Wi-Fi network, WAN, LAN, MAN, Internet, and/orany other network, as well as using a direct connection. Cloud serversand/or on premise servers can be used to provide connection between thestation 960, the system 950, the system 940 and/or the server 930.

In some exemplary implementations, the system 900 can be implemented ina hotel and/or a facilities management setting. Device 910 can includeat least one of the following: a door lock mechanism in a hotel, office,home, locker room, amusement park entrance, a security sensor, autilities management sensor (e.g., air conditioning, heating, lighting,etc.), automotive keyless entry system, e.g., automotive keyless entryfor a rental car and/or car sharing, and/or any other device. Device 920can be a mobile telephone, a smartphone, a tablet, a personal computer,a laptop, and/or any other device. The sever 930 can be a cloud serverand/or any other type of server. The server 930 can perform processingand/or storage of data and can include one or more processors and/ormore memory locations.

The server 930 can manage device 910 and/or device 920. The server 930can also communicate with the security system 950 to record dooroperations as well as with the reservation management system 940 tomanage door operation authorizations. This way, the server 930 candirectly activate and/or deactivate device 920's ability to lock/unlockand/or control device 910. In some implementations, the server 930 canalso collect and store door lock operation information such as when adoor is open/closed and how it was done. The devices 910, 920 can alsoperform functions that are similar to the functions of devices 810 and820 shown in FIG. 8, respectively.

FIG. 10 illustrates yet another exemplary system 1000, according to someimplementations of the current subject matter. The system 1000 can besimilar to the system 900 shown in FIG. 9 and can include a pairingdevice 1 1010, a communication device 2 1020, a server 1030, anoperation management system 1040, a security system 1050, and an onboardtelematics system 1060. The onboard telematics system 1060 can be partof the device 1010, all of which can be incorporated into a vehicle1002.

The devices 1 and 2 can be communicatively coupled with a BLUETOOTH®connection and/or any other connection. Device 2 and the server 1030 canbe communicatively coupled via a network, e.g., a mobile Wi-Fi network,WAN, LAN, MAN, Internet, and/or any other network. The system 1040 canbe communicatively coupled with the server 1030 using a network, e.g., amobile Wi-Fi network, WAN, LAN, MAN, Internet, and/or any other network,as well as using a direct connection. The system 1050 can becommunicatively coupled with the server 1030 using a network, e.g., amobile Wi-Fi network, WAN, LAN, MAN, Internet, and/or any other network,as well as using a direct connection. The system 1060 can becommunicatively coupled with the device 1010 using a network, e.g., amobile Wi-Fi network, WAN, LAN, MAN, Internet, and/or any other network,as well as using a direct connection, such as a USB. Additionally, thesystem 1060 can also be communicatively coupled with the server 1030 viaa network, e.g., a mobile Wi-Fi network, WAN, LAN, MAN, Internet, and/orany other network, as well as using a direct connection. Cloud serversand/or on premise servers can be used to provide connection between thesystem 1060, the system 1050, the system 1040 and/or the server 1030.

In some exemplary implementations, as stated above the system 1000 canbe implemented in a vehicle setting, i.e., device 1010 and system 1060can be part of the vehicle 1002. Device 1010 can include at least one ofthe following: a door lock mechanism, an engine ignition, a navigationsystem, a content purchase system, etc. in a vehicle 1002. Device 1020can be a mobile telephone, a smartphone, a tablet, a personal computer,a laptop, a vehicle key (e.g., a key fob, etc.), and/or any otherdevice. The sever 1030 can be a cloud server and/or any other type ofserver. The server 1030 can perform processing and/or storage of dataand can include one or more processors and/or more memory locations.

The server 1030 can manage device 1010 and/or device 1020. The server1030 can also communicate with the security system 1050 to recordvehicle operation record and driver information as well as with theoperation management system 1040 to manage user operation authorization.This way, the server 1030 can directly activate and/or deactivate device1020's ability to lock/unlock and/or control device 1010 (and thevehicle itself). The server can prompt the device 1010 to broadcast usershared key to confirm the driver information, i.e., the driver is theperson that is supposed to be driving the vehicle 1002. Upon receiving aresponse from device 1020, the driver information is confirmed. Thedevices 1010, 1020 can also perform functions that are similar to thefunctions of devices 810 and 820 shown in FIG. 8, respectively.

In some implementations, devices 1010 and/or 1020 can initiatebroadcasting independently of each other. The device 1020 can broadcastuser shared key and commence communication with device 1010 to open thedoor, start engine, etc., provided that device 1010 responds only to theuser shared key from device 1020. Device 1010 can start broadcastinguser shared key and confirm that the driver has the device 1020 (e.g.,vehicle key fob) by receiving response from device 1020. In someimplementations, devices 1010 and 1020 can be interchangeable and bothcan be performing scanning, i.e., in stealth mode.

In some implementations, when one of the pairing devices is reset to aninitial setting, that device will not respond to the user-specificshared key. It would only respond to the global shared key.

In some implementations, a different user-specific shared key can beassigned to each pairing devices in a multiple-pairing device system.The server can record user-specific shared keys for each device andassociate them with the user account, if appropriate. The communicationdevice can broadcast multiple advertising packets. Each packet cancontain one user-specific shared key for each device so that thecommunication device can selectively communicate with one or morepairing devices. In some implementations, the advertising packet canalso contain multiple user-specific shared keys so that thecommunication device can initiate communication with a plurality ofpairing devices contemporaneously.

In some implementations, when the pairing device is reset to an earliersetting (e.g., an initial factory default setting), the pairing devicecan neglect shared key(s) associated with a user account and onlyrespond to the global shared key. The communication device can send acommand to the pairing device to deactivate such user-specific sharedkey(s). As a result, the pairing device can become ready to be linkedwith a new user account, such as, upon deactivation of a user-specificshared key. The pairing device can be linked with the same account, ifthe same user chooses to do so.

In some implementations, the pairing device can have only one shared keyactive, which can be a global shared key and/or a user-specific sharedkey. The pairing device then can have multiple keys to compare with thecontent of the advertising packet(s) that it receives.

In some implementations, the communication device can instruct theserver to move the shared key information to a list of previously sharedkeys. This way, if an error occurs during replacement a shared key onthe pairing device, this can allow the communication device to attemptto use previously used shared keys to communicate with the pairingdevice.

In some implementations, a user can request to terminate access to oneor more communication devices using user account credentials.Alternatively, the user can terminate access by the user account withregard to a specific communication device associated with the accountbut not to others. Thus, if access to one communication device isterminated and the user is attempting to use another communicationdevice with the same credentials, the access would not be permitted andthe user will be prompted to login. Additionally, the communicationdevice can determine whether or not the user's login information isvalid or not. If not, the user will not be permitted to login.

In some implementations, the user can remove a particular pairing devicefrom being associated with the user account, such as when the userdetermines not to use a particular pairing device anymore, or when theuser has lost the pairing device, and/or for any other reason. In someimplementations, the communication device can be provided with devicemanagement options that can allow the user to register and/or remove oneor more pairing devices.

In some implementations, pairing devices can perform scanning forcommunication devices, advertising packets, shared keys, global sharedkeys, user specific keys, etc. at predetermined intervals. Further, whena user registers a particular pairing device, e.g., a device that hasbeen accessed by the user, the pairing device's scanning interval can beshortened (e.g., from 2 seconds to 0.5 second). When the user removes orun-pairs a particular pairing device from the user account, the pairingdevice can be reset to a default setting. The default setting for thepairing device can include scanning only for one or more global sharedkeys. Once the pairing device is reset, it can become ready to be linkedwith a new user account and/or any previously used user accounts.

In some implementations, when a packet exchange flow between the pairingdevice and the communication device stops unexpectedly and/or responsepackets are not received within a predetermined time period, the pairingdevice and/or the communication device can enter a waiting mode duringwhich they await for receipt of the response packet. The waiting periodallowed can vary depending on various conditions, such as, the pairingdevice and/or the communication device's battery level, and/or any otherconditions.

In some implementations, the current subject matter's selective-pairingtechnology can be implemented on additional devices that can be pairedwith one or more data collecting devices like the pairing devicesdiscussed herein. For example, a beacon can be provided with theselective-pairing technology such that it can operate in theselective-pairing mode (“stealth” mode) and can transmit data only whenit receives a valid shared key from a data collection device. Thecurrent subject matter can also perform transitions between variousmodes, including at least one of the following: a beacon mode to/fromstealth mode, a standard broadcast mode to/from stealth mode, a beaconmode to/from a stealth mode to/from a standard broadcast mode, etc. Thetransitions can be performed manually, automatically, based oninstructions received from the communication device, etc.

In some implementations, if a pairing device's connection to a networkis via a wired connection, it is not necessarily continuous. Forexample, in some implementations, the pairing device can be connected toa LAN network only when necessary. In some implementations, pairingdevice can be connected to a computer through USB only when necessary.In these cases, pairing device can send a request to the server to seeif there is any shared key update(s) or to see if there is anything thatneeds to be done. The server and pairing device can decide what to dodepending upon the communication result between the two devices. In caseof continuous connection to the network, the server can initiate ashared key update process or any other necessary tasks because pairingdevice is ready to communicate with the server all the time.

In some implementations, the current subject matter can provide one ormore security levels. For example, in some implementations, a globalshared key can be used to register a new pairing device to a useraccount. Once paired with a communication device, the pairing device canbe programmed to transmit its MAC address and/or product serial number(e.g., hardware ID) to the communication device, and in turn, to theserver. The server can look up the hardware IDs of the pairing deviceand the communication device, against the registered the pairing devicesand the communication devices across the accounts. If the pairingdevice's hardware ID is new, then the server can generate/assign a newuser-specific shared key to the user account. The communication devicecan receive the new user-specific shared key and transmits it to thepairing device so that the pairing device can activate the user-specificshared key. The pairing device can perform the initial pairing with aglobal shared key, that is, a global shared key security level can beset to register the pairing device and making user specific key activeif the pairing device receives it. This is because global key(s) arelikely to be the same across the same make/product type and can berelatively easy to obtain by a third party. In some implementations, ifthe server can determine that the pairing device's hardware ID isassociated with a different account during the registration/initialpairing process, the server can determine the next action(s), including,for example, denying the pairing device's registration to the accountthat requested it. A global shared key security level can be provided toallow only device registration and user-specific key assignment.

In some implementations, the pairing device's connection based onuser-specific key can be allowed to transmit accumulated sensor readingsand its conditions, for example, for a communication device to change amode of the pairing device (e.g. the pairing device can be configured tohave multiple modes to be used by multiple users), to modify one or morethe pairing device's setting (e.g., sensor type change, etc.), to setthe pairing device's state (e.g., set/correct the pairing device'sinternal real-time clock, etc.), and/or to reset the pairing device(e.g., update global shared key and/or user-specified key). Sharedkey-based connection can also allow the communication device to resetthe pairing device to original factory settings, including, for example,nullifying user specific key(s). In some implementations, the shared keyconnection can enable more functionality because a user-specific key isless likely to be stolen, and is thus more secure.

In some implementations, if the pairing device is registered to multipleusers (e.g., multiple accounts), the pairing device can be allowed to beswapped/switched between or among the accounts. In some implementations,each user can only access his/her data. In some implementations, thesecurity level assignment to each user-specific shared key can bedifferent. For example, some users can be provided with root-levelaccess, while other users are not allowed to change the pairing device'ssettings. In some implementations, the root user can have access toeveryone's sensor readings. In some implementations (for example, whenthe pairing device is not a healthcare device), each user-specific key'saccess to each pairing device functions/features can be different.

In some implementations, one or more users can be provided with accessto allow/disallow the pairing device remote software update, in whole orin part, from the communication device. In this case, when the globalshared key or user-specific shared key has security level (e.g.,permission) that allow the pairing device to perform software update,the communication device can send out updated software to the pairingdevice through BLE. In some implementations, the pairing device cannotify the communication device upon completion of the software update.This can provide an additional safeguard against attempt ofhacking/tampering of the pairing device.

Although BLE devices have been discussed herein, these are only used asone example of the wireless technology that is prevalent today; otherwireless technology (e.g., other wireless communication technologyincluding connectionless wireless communication technology) can be usedinstead of or in addition to BLE in some implementations to implementone or more selective pairing features discussed herein.

FIG. 11 is a flow chart illustrating an exemplary process 1100 foroperation of the current subject matter system, according to someimplementations of the current subject matter. At 1110, the pairingdevice can scan for one or more advertising packets. At 1120, thepairing device can check the advertising data packet(s) for a sharedkey, which can be, for example, a global or user-specific shared key. Ifno shared key is found in the advertising packet(s), the pairing devicedoes not respond. The pairing device can respond only when a shared keyis found (e.g., a match with a key that the pairing device is lookingfor is found) in the advertising packet(s), at 1130. As discussed above,the advertising packet(s) can be transmitted by a communication devicevia BLUETOOTH® technology, for example. In some implementations, theshared key can be split up into a plurality of advertising packets, andthe pairing device can reconstruct the shared key from the portions inthe advertising packets.

In some implementations, the current subject matter can include one ormore of the following optional features. In some implementations, theadvertising packet can be transmitted by a communication device.

In some implementations, the shared key is in the same bit/byte formbetween the pairing device and the communication device. In someimplementations, the advertising packet can be transmitted viaBLUETOOTH® technology. In some implementations, the shared key can be aglobal shared key or a user-specific shared key associated with aparticular user.

In some implementations, the method can also include scanning for aplurality of advertising packets, where each advertising packet in theplurality of advertising packets can contain a portion of the sharedkey, checking each scanned advertising packet for the respective portionof the shared key, and responding to the plurality of scannedadvertising packets only when the entire shared key is found. In someimplementations, the method can include authenticating the shared keyusing a digital certificate.

In some implementations, the responding can further include transmittingat least one of the following: a data attribute, a name, a serialnumber, a media access control (“MAC”) address to the communicationdevice and/or a server. In some implementations, the advertising packetcan be encrypted. The advertising packet can include a shared key and atext (e.g., one or more digit of binary data) added to the shared keybefore the shared key and the added text are encrypted. The added textcan be varied for each pairing with the pairing device.

FIG. 12 is a flow chart illustrating an exemplary process 1200 foroperation of the current subject matter system, according to someimplementations of the current subject matter. At 1210, a server canauthenticate a user, e.g., via a login process. Once the user isauthenticated, the server can determine whether a pairing device, whichthe user wants to pair, had been previously paired, at 1220. If thepairing device had not been paired previously, the server can generateand/or retrieve a shared key, at 1230. The server can transmit theshared key to the paired device, e.g., directly and/or via acommunication device, at 1240.

The current subject matter provides many advantages. By providingdevices that only respond to advertising packets with one or more sharedkeys, the device can operate in a selective pairing mode (or “stealth”mode) such that others would not be aware of its presence or existence.This can enhance privacy and achieve lower power consumption. In someimplementations, enhanced privacy and/or security can also be providedby utilizing one or more features of the current subject matter. In someimplementations, the current subject matter can reduce the number ofdevices broadcasting in an area. This can, for example, enhanceusability and simplify device management. In some implementations, thecurrent subject matter can discourage theft of the devices because thethief would not have access to a shared key that is needed to receive aresponse from the pairing device.

As discussed above, the current subject matter can also providedifferent types of shared keys including, for example, global and/oruser-specific shared keys. One or more shared keys can be shared withone or more selective pairing devices and/or other communicationdevices. This way, the typical device pairing process between thecommunication device and the pairing devices (and/or other communicationdevices) can be avoided, even if the devices are communicating with eachother for the first time.

One or more aspects or features of the subject matter described hereincan be realized in digital electronic circuitry, integrated circuitry,specially designed application specific integrated circuits (ASICs),field programmable gate arrays (FPGAs) computer hardware, firmware,software, and/or combinations thereof. These various aspects or featurescan include implementation in one or more computer programs that areexecutable and/or interpretable on a programmable system including atleast one programmable processor, which can be special or generalpurpose, coupled to receive data and instructions from, and to transmitdata and instructions to, a storage system, at least one input device,and at least one output device. The programmable system or computingsystem may include clients and servers. A client and server aregenerally remote from each other and typically interact through acommunication network. The relationship of client and server arises byvirtue of computer programs running on the respective computers andhaving a client-server relationship to each other.

These computer programs, which can also be referred to as programs,software, software applications, applications, components, or code,include machine instructions for a programmable processor, and can beimplemented in a high-level procedural language, an object-orientedprogramming language, a functional programming language, a logicalprogramming language, and/or in assembly/machine language. As usedherein, the term “machine-readable medium” refers to any computerprogram product, apparatus and/or device, such as for example magneticdiscs, optical disks, memory, and Programmable Logic Devices (PLDs),used to provide machine instructions and/or data to a programmableprocessor, including a machine-readable medium that receives machineinstructions as a machine-readable signal. The term “machine-readablesignal” refers to any signal used to provide machine instructions and/ordata to a programmable processor. The machine-readable medium can storesuch machine instructions non-transitorily, such as for example as woulda non-transient solid-state memory or a magnetic hard drive or anyequivalent storage medium. The machine-readable medium can alternativelyand/or additionally store such machine instructions in a transientmanner, such as for example as would a processor cache or other randomaccess memory associated with one or more physical processor cores.

To provide for interaction with a user, one or more aspects or featuresof the subject matter described herein can be implemented on a computerhaving a display device, such as for example a cathode ray tube (CRT) ora liquid crystal display (LCD) or a light emitting diode (LED) monitorfor displaying information to the user and a keyboard and a pointingdevice, such as for example a mouse or a trackball, by which the usermay provide input to the computer. Other kinds of devices can be used toprovide for interaction with a user as well. For example, feedbackprovided to the user can be any form of sensory feedback, such as forexample visual feedback, auditory feedback, or tactile feedback; andinput from the user may be received in any form, including, but notlimited to, acoustic, speech, or tactile input (e.g., push/touch button,etc.). Other possible input devices include, but are not limited to,touch screens or other touch-sensitive devices such as single ormulti-point resistive or capacitive trackpads, voice recognitionhardware and software, optical scanners, optical pointers, digital imagecapture devices and associated interpretation software, and the like.

In the descriptions above and in the claims, phrases such as “at leastone of” or “one or more of” may occur followed by a conjunctive list ofelements or features. The term “and/or” may also occur in a list of twoor more elements or features. Unless otherwise implicitly or explicitlycontradicted by the context in which it is used, such a phrase isintended to mean any of the listed elements or features individually orany of the recited elements or features in combination with any of theother recited elements or features. For example, the phrases “at leastone of A and B;” “one or more of A and B;” and “A and/or B” are eachintended to mean “A alone, B alone, or A and B together.” A similarinterpretation is also intended for lists including three or more items.For example, the phrases “at least one of A, B, and C;” “one or more ofA, B, and C;” and “A, B, and/or C” are each intended to mean “A alone, Balone, C alone, A and B together, A and C together, B and C together, orA and B and C together.” In addition, use of the term “based on,” aboveand in the claims is intended to mean, “based at least in part on,” suchthat an unrecited feature or element is also permissible.

The subject matter described herein can be embodied in systems,apparatus, methods, and/or articles depending on the desiredconfiguration. The implementations set forth in the foregoingdescription do not represent all implementations consistent with thesubject matter described herein. Instead, they are merely some examplesconsistent with aspects related to the described subject matter.Although a few implementations have been described in detail above,other modifications or additions are possible. In particular, furtherfeatures and/or implementations can be provided in addition to those setforth herein. For example, the implementations described above can bedirected to various combinations and subcombinations of the disclosedfeatures and/or combinations and subcombinations of several furtherfeatures disclosed above. In addition, the logic flows depicted in theaccompanying figures and/or described herein do not necessarily requirethe particular order shown, or sequential order, to achieve desirableresults. Other implementations may be within the scope of the followingclaims.

What is claimed:
 1. A computer-implemented method, comprising: scanning,by a pairing device, for an advertising packet; checking, by the pairingdevice, each scanned advertising packet for a shared key; andresponding, by the pairing device, to the scanned advertising packetonly when the advertising packet contains the shared key.
 2. The methodaccording to claim 1, wherein the advertising packet is transmitted by acommunication device.
 3. The method according to claim 2, wherein theshared key is in the same bit/byte form between the pairing device andthe communication device.
 4. The method according to claim 1, whereinthe advertising packet is transmitted via BLUETOOTH® technology.
 5. Themethod according to claim 1, wherein the shared key is a global sharedkey.
 6. The method according to claim 1, wherein the shared key is auser-specific shared key associated with a particular user.
 7. Themethod according to claim 1, further comprising scanning, by the pairingdevice, for a plurality of advertising packets, each advertising packetin the plurality of advertising packets containing a portion of theshared key; checking, by the pairing device, each scanned advertisingpacket for the respective portion of the shared key; and responding, bythe pairing device, to the plurality of scanned advertising packet onlywhen the entire shared key is found.
 8. The method according to claim 1,further comprising confirming, by the pairing device, that theadvertising packet contains the shared key that the pairing device isscanning for; and authorizing, by the pairing device, a user based onthe confirmed shared key.
 9. The method according to claim 1, whereinthe responding further comprises transmitting one or more of dataattributes, name, serial number, MAC address to a communication deviceor a server.
 10. The method according to claim 1, wherein theadvertising packet is encrypted, the advertising packet comprising theshared key and a text added to the shared key before the shared key andthe added text are encrypted.
 11. The method according to claim 10,wherein the text is varied for each pairing with the pairing device. 12.A system comprising: at least one data processor; memory storinginstructions which, when executed by the at least one data processor,causes the at least one data processor to perform operations comprising:scanning, by a pairing device, for an advertising packet; checking, bythe pairing device, each scanned advertising packet for a shared key;and responding, by the pairing device, to the scanned advertising packetonly when the advertising packet contains the shared key.
 13. The systemaccording to claim 12, wherein the advertising packet is transmitted bya communication device.
 14. The system according to claim 13, whereinthe shared key is in the same bit/byte form between the pairing deviceand the communication device.
 15. The system according to claim 12,wherein the advertising packet is transmitted via BLUETOOTH® technology.16. The system according to claim 12, wherein the shared key is a globalshared key.
 17. The system according to claim 12, wherein the shared keyis a user-specific shared key associated with a particular user.
 18. Thesystem according to claim 12, wherein the operations further comprisescanning, by the pairing device, for a plurality of advertising packets,each advertising packet in the plurality of advertising packetscontaining a portion of the shared key; checking, by the pairing device,each scanned advertising packet for the respective portion of the sharedkey; and responding, by the pairing device, to the plurality of scannedadvertising packet only when the entire shared key is found.
 19. Thesystem according to claim 12, wherein the operations further compriseconfirming, by the pairing device, that the advertising packet containsthe shared key that the pairing device is scanning for; and authorizing,by the pairing device, a user based on the confirmed shared key.
 20. Thesystem according to claim 12, wherein the responding further comprisestransmitting one or more of data attributes, name, serial number, MACaddress to a communication device or a server.
 21. The system accordingto claim 12, wherein the advertising packet is encrypted, theadvertising packet comprising the shared key and a text added to theshared key before the shared key and the added text are encrypted. 22.The system according to claim 21, wherein the text is varied for eachpairing with the pairing device.
 23. A non-transitory computer programproduct storing instructions, which when executed by at least one dataprocessor of at least one computing system, implement a methodcomprising: scanning, by a pairing device, for an advertising packet;checking, by the pairing device, each scanned advertising packet for ashared key; and responding, by the pairing device, to the scannedadvertising packet only when the advertising packet contains the sharedkey.